[レポート] Regional Scrum Gathering Tokyo 2023 に参加してきました #RSGT2023

深澤豪

2023.01.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ふかさわです。 2023年01月11日(水)〜2023年01月13日(金)の3日間、現地(東京：御茶ノ水ソラシティカンファレンスセンター)及びリモートでのハイブリッドで開催された日本最大のスクラムのカンファレンスである『 Regional Scrum Gathering℠ Tokyo 2023 』に参加してきました。そのセッションレポートになります。

ボランティアスタッフで参加した藤村新さんの記事はこちら #RSGT2023 でボランティアスタッフやってみた

Day1

Welcome Note

最初にパックマンルールの話がありました。複数人で会話する場合に、他の人が会話に入って来やすいように、少し場所を開けておこうという話でした。今後も色々な場面で活躍しそうです。 The Pac-Man Rule at Conferences — Eric Holscher

David Bernstein - Five Practices for Building Software with Scrum

サマリ

欧米でスクラムは人気があるが、XPに由来する技術的なプラクティスはそれほど広がっていないということで、CI, CD, TDD, リファクタリング, ペアプログラミングについて、なぜそれが有効なのかや、ポイント等の紹介でした。

特に印象に残ったトピック

ペアプログラミング
- 例として、本棚を運ぶのに一人で重いなら二人で運ぶのと同じ。一人で考えるには複雑なことを2つの頭を使って考える -> 分かりやすい例えでした
- 時間が15%増える、コードが減る、欠陥が減る、集中を中断しにくい、知識がチームで早く広がる、学びが多く満足度が高い、早くリリースできる
- 常に誰かをメンタリングし、誰かからメンタリングされなさい -> ペアプログラミング/ワークの学びが多い理由なのかもしれない
クリーンコード
- 品質を上げよう。そすればより多くの事ができる
TDD
- TDDは設計手法
- HowではなくWhat（振る舞い）にテストを書こう
- テストコードも重要なコード（なのでリファクタリングが必要）
- TDDは振る舞いを正確に表現する
リファクタリング
- 例として、パーティの準備をする前に家のキッチンを片付けるのと一緒
- 他の例として、高級な車を買っても全く修理やメンテナンスしないということはない
- 将来のコードの読者に有益 -> 将来の自分（達）にも有効そう

Kazuhide Inano - アジャイルコーチング × システムコーチング〜Agile & ORSC are eating the world〜

サマリ

ORSC=システムコーチングについてトレーニングを受けてる稲野さん。ここでいうシステムとは二人以上の共通の目的を持った関係性でそれに対するコーチングがORSC。その中でもコアになる考え方の紹介でした。

印象に残ったトピック

技術的課題と適用課題があり、価値観や関係性が絡む適用課題は技術的課題のようにトレーニングやツール等で同じように扱うと失敗しがち -> やりがち
変革は内面/外面/個人/組織の要素を必要とするが、内面は時間がかかるため、ないがしろにされがち（だが重要）
大事にしてること: オープンでいる、自分でエッジを超えてみせる、諦めない -> 自分から行動するということか

アカツキ石毛琴絵- アジャイルな組織改善〜手法とマインドセット〜

サマリ

組織改善において、関係する様々な立場の人を巻き込んで進める必要が出てきます。その時の進め方を他者と自分に注目しての紹介でした。

印象に残ったトピック

お互いの正義で殴り合いしても、良かれと思って伝えた事が却下される
- なぜ分かってもらえないんだ.. になりがち -> よくある
相手のナラティブ（≒その人の解釈）を理解する事が重要
- 同じ言葉でも人によってその解釈は様々 -> 同じ単語でもイメージしてることが違う
システムを変えることは、こだわりや文化を変える事なので時間がかかる
自分の軸を持つ
勇気大事

スプリントレビューDeepDive

サマリ

スプリントレビューについて、具体例や、もし〜したらどうなる？など現場でよくありそうな事象を交えての紹介でした。

印象に残ったトピック

ステークホルダーの種類によっていつ呼ぶかを分類してみよう
スクラムガイドはゴール志向
- プロダクトゴール - スプリントゴール
プロダクトの価値はチームの外側で決まる -> だからスプリントレビューにステークホルダーを呼ぶ必要がある
フィードバックのしかたで集まる情報が変わる
- 音声 / チャット / 匿名の付箋やチャット -> 力関係や得意不得意があるので、誰のどんなフィードバックを得たいかによって方法を変えてみよう

Day2

The Agilists’ Emerging Superpower and Our Planetary Challenge Lyssa

サマリ

現在の組織は機械的な物から熱帯雨林的なものになってきています。また、世界は変化と安定をくりかえし、その速度は指数関数的に高り続けています。その中でアジャイルは何なのか、私達はどう振る舞うべきかを紹介しました。また、後半では地球規模の課題である気候変動に対して、分断している現在と再統合を提案しました。

印象に残ったトピック

アジャイルは変化を代謝させるのには適している、私達のスキルで変化を栄養に変えていく。そして変化は終わらない
変化は外からやってきて、心地よいと思わない方法でやってくる事もある
何かアクションを起こす等エッジを渡ってほしい、勇気を持って重要な会話をしよう
障害を解決する2ステップ
- 自分の内側の準備: 自分の中で整理整頓する（感情でぐちゃぐちゃになってるから）
- 自分の外側の準備: 自分の意図をしっかり咀嚼し、人と話して練習してフィードバックをもらう -> なかなかここまでやらない
どの時代も行動する人がいる

ソフトウェア開発関係ない人向けに作ってみた、アジャイルにものを作るってどういうことか？

サマリ

プロダクトの成長を例に、その時期その時期で作るものの考え方、また作るためのアプローチやチームに対する考え方などをモデル、論文、ツールなどを絡めての紹介でした。

印象に残ったトピック

KANOモデル: その時代時代で業界の競争の基準が変わってくる（車なら走る曲がる - 速いスピード - ABSやエアバッグ - 自動運転など） -> 一つのプロダクトの段階もそうだが、成熟した業界や分野なのかどうかによっても変わる
作る都合（イテレーティブ）と確かめる都合（インクリメンタル）をうまく両立する
ソフトウェアはコピーできるが、作るチームは他に変え難くコピーできないので維持してチームの競争力を上げよう -> だいじ

自治体DXにアジャイルなマインドとスキルはどれほど役立つのか

サマリ

月に数日のリモート副業で自治体向けDXの仕事をしている、岡島さんのお話しです。今までのどんな経験がどう生きるのか、ツボ探求力、右腕力、民間活力に分けてを紹介しました。

印象に残ったトピック

システムの構造を見出して介入点（レバレジポイント）を掴む -> 全体を見て小さな力で大きな効果を出せそうな場所に働きかける≒費用対効果の高いところからやる、と似てる
本当の狙いはカルチャーの変化 -> 確かにそうなると自分が居なくても物事が進むようになる
町の人が回覧板を個人でデジタル化して既成事実化した取り組みを見て、中の人（当事者/利用者）になるのは強いと感じた -> 前日の最後のセッションでもあったが当事者が自分の持っている課題を解決するのは、自分ごとにできて課題を理解して、少なくとも一人の課題が解決できる意味でも強い

「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法

サマリ

プロダクトが成長していく段階で分業が始まり、プロダクトマネージャーと開発者のプロダクト開発についての経験のギャップが開いていきます。その結果プロダクトマネージャーがボトルネックになり様々な問題が生じます。なので、チームでプロダクトマネジメントしようという提案でした。

印象に残ったトピック

何を解くかの次にどう解くか（Issueからはじめよ）の順番が大事 -> PdMとDevの間に壁があるとお互いの状況が見えにくいから良くない順番になりそう
- はやいやすいまずい牛丼 - 客がつかない - 解く価値の低い問題を解決の質を高く解く ☓
- おそいたかいうまい牛丼 - 初期やすごい美味しいと客がつく - 解く価値の高い問題を解決の質を低く解く、から始める◯
価値の高い問題の発見と、解決の質の高さのどちらどれだけ時間（コスト）をかけてるか計測してみよう - それって適切？ - これに限らず何にどれくらいコストをかけてるか認識するところから色々始まりそう。ダイエットしかり
サイドB: 僕（開発者）は本当にプロダクト開発をしたいのだろうか？から始まる -> 最後のこれが一番印象的で‥プロダクトマネージャーと開発者が協調して進める形が一段階進む or 戻るんだろうと思ったし、共感した

The Stable Team - 機能する安定したチームをつくる

サマリ

様々な書籍や研究から、安定したチームは良さそうとだと言われています。しかし実際には様々な理由で流動的になる状況もあります。安定とはどういうことなのか？を理解して、機能する安定したチームをどうやって作っていくのかの例の紹介でした。

印象に残ったトピック

安定したチームでパフォーマンスが出ない組織では流動的なチームで成功する可能性はほとんどない
様々な変化が起きてもパフォーマンスが発揮できる状態にすぐに回復できるレジリエンスの高さが安定したチームの特徴の一つ -> 変化を固く跳ね返すのではなく、変化に対して自分達がうまく適応できるイメージ
人の移動を意図を持って行おう
チームが長く続いてると人生を共に歩んでるように感じる -> 思いかえすと長く居たよいチームのメンバーには特別な感情を持ってる